A network address translator (NAT) enhances the security of the network by obscuring the internet protocol (IP) addresses of nodes on the network, thus preventing the nodes from being directly reachable from outside of the network. However, the NAT may also cause issues in real time communications because nodes within the network may not be directly able to receive incoming calls, sessions, communications, dialogs or transactions from outside the network.
The NAT may also be co-located with a firewall. In order to overcome the hindrance caused by a NAT/firewall, various solutions exist. Session Traversal Utilities for NAT (STUN), as defined by the Internet Engineering Task Force (IETF) Request For Comments (RFC) 5389, “Session Traversal Utilities For NAT (STUN)”, the contents of which are incorporated herein by reference, provides a way for a Client software on an IP node to learn its assigned address and port on the NAT observed from other networks outside of its network, such as IP nodes on the other side of the NAT. Due to the varieties and complexity of the NAT/firewall functions, STUN itself is not enough to allow incoming traffic to traverse a NAT.
Traversal Using Relays Around NAT (TURN), as defined in IETF RFC 5766, “Traversal Using Relays Around NAT (TURN): Relay Extensions To Session Traversal Utilities for NAT (STUN)” the contents of which are incorporated herein by reference, introduces a “Man-In-The-Middle” type server that relays, proxies, or transfers the IP data traffic on behalf of a Client behind the NAT, thus allowing that Client to be reachable from the other side of the NAT. A TURN server relays the traffic between two communicating points. The TURN protocol allows a host behind a NAT, herein called a TURN Client, to request that another host called the TURN Server acts as a relay. TURN is an extension of STUN and most TURN messages have the same formatting as their STUN equivalents.
TURN does not provide a way to communicate a Client's relayed transport address to its Peers, nor does it provide a way for the Client to learn each Peer's external facing IP address and port, which would be a “server-reflexive transport address” if the Peer is also behind a NAT. Other protocols and solutions exists for such communications, including session initiation protocol (SIP) and Interactive Connectivity Establishment (ICE), as defined in IETF RFC 5245, “Interactive Connectivity Establishment (ICE): A Protocol For Network Address Translator (NAT) Traversal For Offer/Answer Protocols”, the contents of which are incorporated herein by reference.
However, in some networks, a firewall may restrict TCP connections to use only certain ports. This may be done, for example, for security or privacy reasons. For example, in some networks only TCP ports 80 and 443 may be open for TCP. TCP port 80 is typically used for the hypertext transfer protocol (HTTP) and port 443 is typically used for HTTP with transport layer security (TLS), also known as HTTPS. Such ports may only be allowed for outbound TCP connections in order to enable users to access the World Wide Web but nothing else. Other ports may be allowed in addition to, or alternatively to, those above. The restriction of ports is common in many corporate or enterprise network environments, which are referred to herein as a “restricted-access network environments”.
In a restricted-access network environment, a TCP TURN Server Solution may not work since the TCP TURN Server assigns Clients unique ports to uniquely identify the Client, and such port access may be restricted through the firewall.